NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/8963

Internet Message Format | 1996-08-05 | 3.6 KB

Path: armltd.co.uk!dseal
From: [e-mail] (David Seal)
Newsgroups: comp.arch.arithmetic,comp.lang.c,comp.lang.c++
Subject: Re: Access carry flag from C
Date: 27 Feb 1996 17:02:55 GMT
Organization: Advanced RISC Machines Ltd
Message-ID: <4gvdfv$[e-mail]>
References: <[e-mail]> <[e-mail]>         <[e-mail]> <danpop.824859220@rscernix>         <[e-mail]> <[e-mail]>         <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: sun11.armltd.co.uk

Franz Korntner <[e-mail]> writes:

>Tanmoy Bhattacharya wrote:
>> It states explicitly that INT_MAX is the maximum value of type int
>> ... how do you read anything else?
>
>As I said, I don't have a copy of the standard at the moment (My
>company is large, and I cant find the only copy). but the following
>
>>         The values given below shall be replaced by constant expressions
>>         ... Their implementation-defined values shall be greater in magnitude
>>         (absolute value) to those shown, with the same sign.
>
>does imply that the implementation defined values (the plysical limit) shall
>be greater than the shown constants. thus INT_MAX is a minimal limit as the
>implementation defined maximum can (and according to the above- will be) larger
>than the constant. Right ?!?

There are three values to consider from the standard:

(1) +32767

(2) INT_MAX (or to be completely precise, the constant expression that
    INT_MAX is expanded to by the preprocessor).

(3) The maximum value that the implementation allows a variable of
    type "int" to take before undefined behaviour occurs.

As you say, the standard says that +32767 is the smallest value that
INT_MAX may be - i.e. that value (1) <= value (2). But as Tanmoy
Bhattacharya points out, it *also* says that value (2) is *equal* to
value (3). In short, the requirements imposed by the standard are:

  Value (1) < Value (2) = Value (3)

and if I read you correctly, you're instead interpreting them as:

  Value (1) < Value (2) < Value (3)

I.e. while +32767 is indeed a minimum for INT_MAX, this isn't the only
constraint on INT_MAX: it must *also* be equal to the physical limit
your implementation imposes.

Having said this, in the case of INT_MAX, there is a let-out clause:
the behaviour of "int" arithmetic above INT_MAX is undefined. That
means that it can be anything you like: it can even be perfectly
standard signed arithmetic up to a higher limit. As a result, it is
legitimate (though perverse) e.g. to produce an implementation in
which "int" arithmetic is done as absolutely standard 32-bit
arithmetic, while you define INT_MAX to be 1048575. What this
effectively means is that you are only guaranteeing "int" arithmetic
up to 1048575, but in fact supplying a version which works up to
2147483647.

The overall result is that INT_MAX + 1, calculated using "int"
arithmetic, must be undefined on every implementation. This doesn't
necessarily mean that it will overflow; it does necessarily mean that
a programmer should not rely on it being correct.

In the case of UINT_MAX, the stronger requirements of the standard for
"unsigned" arithmetic lead to somewhat different conclusions:

* UINT_MAX is required both to be at least 65535 and to be equal to
  the maximum unsigned value that can be represented.

* UINT_MAX + 1, calculated using "unsigned" arithmetic, is required to
  be 0.

So the corresponding let-out clause does not exist for unsigned
arithmetic: it is effectively required to be precisely the maximum
implemented unsigned value.

David Seal
[e-mail]